「UGeek大咖说」大厂可观测系列之【百度专场】已经告一段落，小编周末加班吐血整理出亮点回顾，回馈下全程参与直播的观众同学们，也弥补下没能观看到直播的热心粉丝。下面进入回顾时间。


嘉宾简介
李道伟老师，百度YY直播监控负责人，从事运维监控告警相关平台建设，负责YY直播运维服务治理平台、计算平台建设
演讲主题
YY直播亿级可观测监控实践
主题介绍
#  YY直播Metrics与Trace监控系统建设、应用、稳定性相关实践
#  后期结合服务治理，打通应用与监控告警之间的关系
#  微服务监控、系统架构高可用

讲师分享



# 为什么要做服务治理：复杂业务往往由很多系统构成，不同系统之间的数据之间相互独立，如果没有统一的服务治理，业务运维要在多个系统之间去切换，运维流程也不可能打通，服务治理平台对IT环境的服务进行集中管理，接入服务治理平台，运维系统才能实现一体化的业务运维。

# 如何打通监控与服务治理：在实际的运维场景，需要对系统的监控数据进行关联，以一个多实例部署的应用运维为场景，需要将主机、业务、Trace、日志、告警和服务之间建立关联关系，一旦服务发生告警的话，可以将采集上来的监控数据和对应的服务实现自动化关联，包含主机、容器、Pod信息、机房网络、业务方上报的数据，基于Metrics、奥秘、APM、Trace的监控数据做不同告警类型分类与动态分析，通过告警去撰取对应的数据，帮助解决和定位具体的故障问题。

# 监控数据采集与存储模式相关分析：针对监控数据开发统一数据通道，先把数据分发到Kafka，通过Flink发放任务清洗数据，清洗过后有些会继续回流打卡，有些会去到HDFS，还会做元数据的离线处理，最后做相应的UI版式。

# 数据通道高可用实现：Agent完全内部自研，对接SDK，比如Metric监控、Aomi监控、主机上面各种脚本采集到的数据都会流通Agent，Clarke基于GRPC做了定制化开发，高可用会有两个集群去发送相同的数据，后面处理数据都是单独流程，数据量突发集群可以快速切换去做相关展示与告警处理，主域名与备域名动态切换，服务发现系统注册中心是用Console双集群。

# Metrics数据：内部定义多个维度，比如指标有区域XP、IDC、Host，通过不同维度去存储，比如指标单存储一份数据，IDC也会去存储数据，方便快速查询，相当于空间换时间的实现，数据底层目前是用HBase去做相关存储，离线现在是通过HDFS去做离线任务的数据修正，实时数据的及时率97%左右，针对实时数据在实时分析后会做离线分析处理，还会做离线数据的聚合处理，相当于是对实时的补充。

# Trace监控：用来解决多服务之间请求与质量的追踪，基于Jaeger定制化开发Clarke模块，Trace原始数据分发到Kafka和日志平台，Clarke后端上传和流转数据分发定制，去做服务拓扑、延时数据、错误数据的分析，计算任务通过Flink去做，数据存储到Druid。

# 如何做到服务端到客户端Trace的全链路打通：集成Jaeger的SDK，Trace相关数据通过SDK自动生成上报，跨服务数据通过SDK提供的API对Trace的ID做相关处理，全链路Trace配置监控目前手机客户端APP没有采用Jaeger的SDK，因为SDK对性能损耗很大，所以现在定制Trace协议，客户端上报数据集成Trace信息，针对APP做出特殊业务处理，客户端指定特殊标志，有特殊标志就不会去做抽样而是去做全采，将Trace的ID透传到服务端，自研的APM监控也会做数据关联，形成全链路打通。

# 多个监控系统的融合：我们大部分监控系统都是之前自研的SDK，多个监控系统针对的数据不同，业务方去接入SDK也是比较麻烦，业界有推出OpenTelemetry协议，集成Metrics、Trace、日志，解决SDK的融合难题，目前在做相关自研，「优维」也是推出了「超融合监控」的解决方案，融合监控系统的所有信息，也是YY直播未来发展的看齐方向。

问答环节

本次直播观众们的提问热情也是空前高涨，参与感拉满，也是一度让讲师被讨论区的问题弹幕挡住了屏幕看ppt的视线！什么叫学术交流氛围啊（战术后仰）？

↓↓↓

Q1：运维行业能否总结出监控成熟度的模型？

A1：行业里面是有标准模型的，像Trace和Metrics都是比较成熟的模型，而且「优维超融合监控」也是业界典范，提供了一套完善的解决方案 。

Q2：YY直播监控体系的可观测涉及到哪些方面？

A2：主机监控、容器的Pod监控、业务的Trace监控、自研的Aomi监控，服务治理平台对应的Dashboard把所有监控数据整合到一起给到业务方去查询分析。

Q3：怎样从体系设计上彻底解决告警风暴？

A3：通过一些技术手段和业务手段对告警进行动态分类，依据对程序的判断，同一类型的告警短时间内只发出一条。

Q4：YY直播运维团队是如何去做故障问题定位的？

A4：基于告警这一模块，处理问题会优先去看现在有没有告警产生，针对告警去做动态分析方案，撰取对应的监控数据，比如主机变更、事件服务发布、发布变更事件、机房网络数据，会整合在一起提供提供出来给业务方对故障做出相关判断。

Q5：YY直播监控体系的建设路径是怎样的？

A5：早期基本也是主机监控，比如内存和CPU，后面的话开发Metrics监控，后续做了Web服务质量相关的监控，针对Trace开发了奥秘系统，这些系统开发完之后针对APP单独开发了APM监控，目前在预研可变维度的监控体系。

Q6：YY直播的应用追踪是如何去做的？

A6：早期自研Aomi系统，主要去做一些跨服务之间的指标监控，后续的话接入Trace，基于Jaeger去做定制开发，数据采集更加灵活，目前在往业界标准化方向发展。

Q7：YY直播立体化监控如何做到链路、指标、日志三种基本监控数据的关联？如何将业务应用资源和链路的功能结合起来的？

A7：统一标准让业务方去把Trace的ID打在日志里面，链路查询根据ID去查询相应的日志，Metrics基于上报的数据去做服务和监控数据的关联，针对服务去做Metrics和Trace数据的关联。

Q8：监控对接有没有标准规范的参考方案？

A8：每个公司由于业务发展都会有所区别，目前业界推动OpenTelemetry协议。

Q9：监控的时效性如何？

A9：我们最快现在是做到1分钟的时延，慢点的时延是在2-3分钟，Metrics和主机监控做到秒级，Tracing分钟级，1分钟左右。

Q10：高可用部署如果是异地灾备，那么集中式采集器如何实现高可用？

A10：我们现在是属于分布式采集，主机数据每台主机有一个单独的Agent，容器目前树主机共享一个Agent，算是少量的集中。

Q11：目前的Trace监控使用了多少服务器资源？

A11：计算现在已经实现平台化了，我们所有的计算任务都是在容器上面跑，计算大概是3000CPU、5000内存的规模。

Q12：全链路有没有考虑SkyWalking？

A12：我们之前有调研过，主要是去对比SkyWalking和Jaeger，SkyWalking有些条件不太满足我们这边的要求。

Q13：调用链可以追踪精确到函数这个颗粒度吗？

A13：全采或者半抽样采的话数据量特别大，我们现在Trace是做到最外层的方法级别，还没有函数级别这么精细。

Q14：数据日均80T，数据是怎么维护的？

A14：存储集群是有专门的DBA去维护的，用的时候有问题的话找相关的DBA去处理。

Q15：1万多台主机类型不一样，阈值也不一样，如何配置告警策略防止误告？

A15：主机监控的阈值告警目前的话采用全网统一的兜底阈值，全网的机器CPU超过75%就会开始告警，当然如果业务方觉得这个阈值太低了或者太高了，就可以自己去针对业务需求去配置相关的阈值，我们会去自己评估，设置一个保底的阈值，然后业务方可以根据实际机器实际的数据去配置更新。

Q16：面对20多万监控对象的应用场景，数据存储方有什么建议的存储方案？

A16：根据实际的业务场景去决定，目前的话我们主要还是HBase和Druid，元数据相关用ES。

Q17：针对历史原因留下的多个监控系统，一般有哪些整合方案可以参考？

A17：主要是要去整合SDK这一模块，因为SDK太多的话对于后续的维护升级都会比较麻烦，因为业务方是会比较频繁去升级SDK的，后续的话我们肯定是会先去做SDK的预研，OpenTelemetry这个协议目前业界已经开始在慢慢去接受了，会去用一个业界比较通用的SDK。

Q18：Trace和APM监控的区别是什么？

A18：数据统计维度有所区别，APM监控属于自定义指标的上报，包含客户端比较关注的指标，比方说手机应用的系统版本、对应的运营方、对应的手机平台，主要去分析APP的整体运营质量，没办法去定位一些比较细节性的具体问题，从手机端到服务端定位具体问题是支持不了的，Trace主要是用来去做链路追踪的分析，没有去采集手机信息，而是去定位故障根因。


UGeek大咖说大厂可观测系列往期回顾：UGeek大咖说第三期【OPPO专场】